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REMARKS 

Claims 38, 40-49, 54, 55, 57, and 58 are pending. 

In an Official Action dated Sep. 25, 2007, all claims were rejected under 35 U.S.C. § 
103. The rejections are respectfully traversed. 

Interview Summary 

Applicants thank the Examiner for the courtesy of a telephonic interview on Dec. 12, 
2007. At the interview, Applicants' undersigned representative raised various of the issues 
presented in this response for the Examiner's consideration. Applicants agreed to prepare a 
written response for the Examiner's further consideration. 

Rejections Under 35 U.S.C. § 103 

Claims 38, 40-49, 54, 55, 57, and 58 were rejected under 35 U.S.C. § 103(a) as 
allegedly unpatentable over U.S. Patent No. 5,634,123 (Bennion) in view of one or more of 
U.S. Patent No. 6,266,673 (Hong), U.S. Publication No. 2004/10220946 (Krishnaprasad), 
U.S. Patent No. 6,012,067 (Sarkar), US Patent No. 6,904,454 (Stickler), and US Patent No. 
6,631,130 (Roy). The rejections are respectfully traversed. 

Claims 38, 40-48 and 58 

Claims 38 and 40-48 were rejected as allegedly unpatentable over Bennion in view 
Hong, and also relying upon Sarkar in the rejection of claims 40-43, and on Stickler in the 
rejection of claims 45-48. Claim 58 was rejected as allegedly unpatentable over Bennion in 
view Roy. Applicants traverse the rejections of these claims over the cited references because 
the references fail to teach or suggest at least, "a binary fragment associated with said object, 
said binary fragment comprising a binary fragment header and a binary fragment payload, 
wherein the binary fragment payload comprises all primitive data members of said object and 
wherein said primitive data members are in a storage engine record format" as recited in 
independent claims 38 and 58. 

The Official Action alleges that this limitation can be found in Bennion. This 
allegation is incorrect for a number of reasons. 
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The Official Action admits on page 4 that Bennion does not explicitly teach "wherein 
the binary fragment payload comprises all primitive data members of said object". However 
the Official Action states that "since each record within the COMPANY object may be 
classified as either a container record or a data-containing record (i.e. a primitive data 
member)(col. 3, lines 19-22, Bennion), it is obvious that said plurality of primitive data 
members are all of the primitive data members of the object." Two mistaken conclusions 
appear in this statement: 

1. First, by stating "a data-containing record (i.e. a primitive data member)" it appears 
the Official Action considers Bennion' s data-containing record equivalent to a primitive data 
member as recited in Applicants' claims. This is incorrect. Bennion makes no mention that 
"data containing records" are equivalent to primitive data members, as the term is understood 
by persons of skill in the art. Instead, Bennion states that "there is provided a system and 
method for data management permitting storage and communication of different types of 
data..." Bennion col. 1, lines 40-42. This statement indicates that Bennion's data-containing 
records could contain a variety of data types, not necessarily including primitive data 
members. 

2. Second, by finding "since each record within the COMPANY object may be 
classified as either a container record or a data-containing record (i.e. a primitive data 
member)(col. 3, lines 19-22, Bennion), it is obvious that said plurality of primitive data 
members are all of the primitive data members of the object," it appears that the Official 
Action considers Applicants' claimed binary fragment to be equivalent to the COMPANY 
container record disclosed in Bennion, e.g. at Bennion Fig. 6, item 600, while Bennion's 
data-containing records would supposedly be equivalent to "all primitive data members of 
said object . . . wherein said primitive data members are in a storage engine record format." 

Assuming, arguendo, that this view of Applicant's above claim limitation and 

Bennion were correct (even though it is not correct - Applicants binary fragment is clearly 

not an assortment of various container records and data-containing records as disclosed in 

Bennion), then a problem arises in the Official Action's assertion on page 6 that Bennion 

discloses "at least one additional fragment comprising at least one non-primitive member of 

the object." The problem is that the Official Action is first asserting that Applicants' claimed 

binary fragment is equivalent to Bennion's COMPANY container record, and therefore 
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contains all of the records for the entire object, and next asserting that Bennion discloses at 
least one additional fragment. In other words, the Official Action is stating that one 
fragment/record contains all records for an object, but then there is at least one additional 
fragment/record. The truth of the first conclusion excludes the possibility of the second 
conclusion. 

Applicants would also like to note for the record that Bennion does not disclose 
primitive data members in a storage engine record format, as stated in Official Action page 4. 
A hierarchical structure as provided in Bennion is not a storage engine record format. Refer 
for example to Applicants' Fig. 10, which illustrates columns and rows. 

Another example of the many inaccuracies that arise in the Official Action's attempt 
to map the teachings of Bennion into the mold of Applicants' claims, when in fact very little 
similarity exists, is found in the Official Action's assertion on page 3 that a binary fragment 
is disclosed by both Bennion Fig. 2, item 200 and 201. Item 200 is a container record {see 
Bennion col. 5, line 10). Item 201 is a data-containing record {see Bennion col. 5, line 30). 
However, Bennion states, "No record is both a container record and a data-containing record. 
Bennion col. 3, lines 23-24. Therefore, it appears the Official Action alleges that "a binary 
fragment" as taught by Applicants' claims is both a container record and a data-containing 
record, in violation of the teachings of Bennion itself. 

The various other references of record fail to cure the deficiency of Bennion. 
Dependent claims 40-48 define over the references for the same reasons as independent claim 
38. 

Claims 49, 54, 55, and 57 

Claims 49 and 54 were rejected as allegedly unpatentable over Bennion in view 
Krishnaprasad, Sarkar, and Stickler. Claims 55 and 57 were rejected as allegedly 
unpatentable over Bennion in view Hong and Stickler. Applicants traverse the rejections of 
these claims over the cited references because the references fail to teach or suggest at least, 
"a collection start fragment comprising a collection start header" as recited in independent 
claims 49 and 55. 
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The Official Action alleges on page 10 (referring to claim 45) that this limitation can 
be found in Bennion. This allegation is incorrect. 

The Official Action apparently concludes that a collection start fragment is equivalent 
to a container record as taught by Bennion. See Official Action page 10, citing Bennion col. 
1, lines 56-63). However, Bennion states that, "container records contain other records." 
Bennion col. 3, lines 22-24. In contrast, there is nothing in Applicants' claims or specification 
to indicate that a collection start fragment would "contain other records." Please refer to 
Applicants' specification paragraph 0049 and Fig. 11(E). 

Furthermore, the conclusion that the claimed collection start fragment is equivalent to 
Bennion' s container record ignores the plain language of the claim. Namely, a collection start 
fragment is a fragment at the start of a collection, not a container of other records as taught 
by Bennion. 

Finally, Applicants point out that, even if the difference between a collection start 
fragment versus a "container" were ignored, there is no teaching or suggestion in Bennion 
that a container record contains a collection. Bennion defines container records as records 
that contain other records, and do not contain data. Bennion col. 3, lines 22-24. In contrast, 
collection data as may be in a collection element payload in Applicants' claims comprises, 
"only a data member of a collection element data type, said collection element data type 
comprising data of a same type as every collection element associated with said collection 
start fragment." See Applicants' claims 49 and 55. Bennion provides no indication that such 
collection data would be contained in a container record. 

Applicants also point the Examiner to additional distinctions between Applicants' 
claims and the references of record that explained in Applicants' previous responses. 
Applicants' response of October 27, 2006 explains on pages 8 and 9 that while in Bennion, 
some records identify themselves as containing other records, or containing data, no records 
identify themselves as starting a collection or as a member of a collection, as recited in 
Appplicants' claims. This same section of Applicants previous response also explains why 
the disclosure of Stickler cannot be said to teach or suggest any aspects of Applicants' claims. 
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The various other references of record fail to cure the deficiency of Bennion. 
Dependent claims 54 and 57 define over the references for the same reasons as independent 
claims 49 and 55. 



Date: December 19, 2007 /Nathaniel Gilder/ 

Nathaniel Gilder 
Registration No. 53,233 

Woodcock Washburn LLP 
Cira Centre 

2929 Arch Street, 12th Floor 
Philadelphia, PA 19104-2891 
Telephone: (215) 568-3100 
Facsimile: (215) 568-3439 



Page 11 of 11 



